IBIS Macromodel Task Group Meeting date: 03 May 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad asked if we should consider cancelling next week's meeting because of the European IBIS Summit at SPI. Walter and Randy said they would be traveling to the Summit and unable to attend. Because they were the only two unable to attend, the group decided not to cancel next week's meeting. ------------- Review of ARs: - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. Ambrish confirmed that he had sent the most recent draft to Arpad prior to the April 19th meeting. Walter and Bob also asked to receive a pre-release copy. Ambrish agreed to send it to them. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Minutes from April 19: - Arpad: Does anyone have any comments or corrections? [none] - Dan: Motion to approve the minutes. - Randy: Second. - Arpad: Anyone opposed? [none] Minutes from April 26: - Arpad: Does anyone have any comments or corrections? [none] - Dan: Motion to approve the minutes. - Mike: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: [Pin Reference] BIRD Draft: - Arpad: Do we have questions, comments, discussion on last week's presentation? - Radek: It is what I have been advocating for some time. - It is definitely a step in the right direction. - Details concerning whether signal_name, bus_label, or another Pin can serve as the reference are to be worked out. But those are details and this feature is important. - Bob: I agree that bus_label vs. signal_name needs to be resolved. - Only I/O Pins should appear, not POWER, GND, NC, or even terminator Models. - Basing things on one reference may not reflect the specifications or internal circuitry of some buffers. That's a concern, and we may need to add a statement to that effect. - Mike: [sharing a new draft of the [Pin Reference] BIRD proposal] - Discussion: Mike noted that he had made some editorial changes. Mike asked whether VT, IV, ISSO all belonged in the same category of voltages that are referenced to some additional reference node in the circuit. After some discussion, the group agreed that IV and ISSO tables were fully specified with respect to the I/O pad and power supply terminals themselves, and therefore could be removed from this [Pin Reference] proposal. Mike noted that Bob preferred that bus_label serve as the reference rather than a signal_name. Radek stated that either one would probably be fine. Mike said that from the EDA tool's perspective it needs to identify some terminal or node to use as the reference, and the question was which one allows the tool to identify the node that is closest to what was actually used at the time of the measurement. Radek said it simply depended on whether [Pin Mapping] were present, and that if [Pin Mapping] were not present then signal_name would be fine. Radek and Walter both supported this sense of signal_name as an implicit bus_label. Bob, however, expressed concern about ambiguities if [Pin Mapping] were not present. For the sake of simplicity in the proposal, therefore, Walter agreed to use bus_label instead of signal_name, which makes [Pin Mapping] mandatory instead of optional [this change is reflected in the posted document]. Bob noted concern over multiple instances of the forward referencing of keywords that were not defined until later. Mike suggested that we should make simple ordering decisions to mitigate those issues where possible, but that we should not let forward referencing derail a good proposal. He also noted that IBIS had always set itself up for forward referencing issues by defining the [Component] keyword first. Arpad noted that in general it was always advantageous to keep most of the information related to a given topic or keyword in one place. Even people familiar with the spec would have to look things up on occasion, and if a keyword's section didn't describe everything then it was easy to miss something. Bob agreed and said that he felt this keyword should be in the [Component] section (section 5) and should include language indicating that certain forward referenced terms are defined later (section 6). Radek suggested that syntax, etc., could be defined in the keyword section itself, but that discussion of effects relative to other keywords could appear with those keywords. - Bob: [sharing an ad hoc presentation on [Pin Reference] Cases] - Discussion: Bob reviewed his presentation including slides illustrating threshold specifications for various technologies. Using CMOS as one example it shows proportional thresholds based on Vcc, e.g., Vil = 0.3*VCC. The presentation describes the term "dominant" reference, and suggests that VCC might be the dominant reference in the CMOS case, but that the thresholds are still a function of the "ground" and VCC. Other technologies and their relationships between thresholds and two different rails were also listed. Walter stated, however, that thresholds should always be expected to vary based on the difference between the two power rails, and that these examples were not unique in relying on two voltage rails. He noted that the existing [Receiver Thresholds] keyword provides an overly simplistic version of this threshold mapping by assuming the "ground" rail is fixed at 0. - Arpad: I think this BIRD will be the topic for next week, so I encourage everyone to review this new draft carefully. - Arpad: Thank you all for joining. ------------- Next meeting: 10 May 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives